Towards Tool-Support for Evolutionary Software Product Line Development

Software vendors often need to vary their products to satisfy customer-specific requirements. In many cases, existing code is reused and adapted to the new project needs. This copy&paste course of action leads a multiproduct code-base that is hard to maintain. Software Product Lines (SPL) emerged as an appropriate concept to manage product families with common functionality and code bases. Evolutionary SPLs, with a product-first-approach and an expost product line, provide advantages such as a reduced time-to-market and SPLs based on evaluated and proven products [3]. In addition to the advantages, the evolutionary derivation of an SPL from existing products approach requires challenging tasks to enforce such a transformation: i) The existing software including the differences between the derivates need to be understood. ii) Furthermore, the common SPL architecture has to be understood and the products have to be refactored into a core with variation points as well as variations that can be instantiated for the derived products. There are existing approaches to introduce and maintain evolutionary SPLs [5],[6]. Most of them start with the requirement specifications and only few consider the analysis of existing software artifacts. The latter often include hidden variation points that might be missed by considering requirements only as described by Schütz et al. [7]. However, Schütz et al. also state that the software analysis and finding of the right variation architecture is often too complex and expensive to be done manually by the developers. In this paper, we present an integrated, toolsupported reverse-engineering, variation analysis, and refactoring approach which transforms similar products to an evolutionary SPL. Introducing automation in that evolutionary SPL approach provides a high potential to reduce the effort of analyzing the products under examination and to support choosing the most appropriate SPL architecture. Companies will benefit from this effort reduction and are supported in introducing an SPL. Our approach is related to the one of Frenzel and Koschke [4], but considers custom SPL characteristics, respects the component-based architecture paradigm (e.g. explicit interfaces) and gives the freedom to choose from multiple possible variation point designs which are evaluated by the approach. In the following, we provide an insight to the individual steps of the proposed process as well as an outlook on how we plan to evaluate the approach and on the future development.